Development
Choosing between portability and innovation
Portability is a key concept in the open source ecosystem. Thanks to this killer feature, your author has migrated his desktop operating system during the last ten years from Mac OS X to Linux (various distributions) and eventually to FreeBSD, but throughout that process he could keep using most of the same applications. When you present a recent openSUSE or PC-BSD desktop system to a computer newbie, they won't notice much difference, apart from a different desktop theme, perhaps. The same applications (OpenOffice.org, Firefox, K3b, Dolphin, and so on) will be available. In many circumstances, it just doesn't matter whether your operating system is using a Linux or FreeBSD kernel, as long as it has drivers for your hardware (and that's the catch).
This portability, however, is not always easy to achieve. Now that Linux is the most popular free Unix-like operating system, it shouldn't be a surprise that some projects have begun treating non-Linux operating systems as second-class citizens. This isn't out of contempt for the BSDs or OpenSolaris, it's just a matter of limited manpower: if almost all the users of the application have a Linux operating system and if all the core developers are using Linux themselves, it's difficult to keep supporting other operating systems. But sometimes the choice to leave out support for other operating systems is explicitly made, e.g. when the developers want to implement some innovative features that require functionality that is (at least for now) only available in the Linux kernel.
Xfce 4.8 and udev
In January, version 4.8 of the Xfce desktop environment was released. In the beginning of its announcement, the developers expressed their disappointment that they couldn't offer all the new features of the release on the BSDs:
This somewhat cryptic remark was followed by a summary of the new features, but it was clear that it was aimed at the new desktop frameworks introduced in the last few years, such as udev, ConsoleKit and PolicyKit. udev is only available on Linux, but both ConsoleKit and PolicyKit are already supported by FreeBSD, so as LWN.net commenter "JohnLenz" supposed correctly in a comment on the announcement, the problem is for a large part on the testing side: how many FreeBSD users are using these frameworks? And how many of them test these frameworks regularly and spend the time to report bugs?
The remark in the release announcement probably puzzled a lot of BSD enthusiasts as well, because Xfce developer Jannis Pohlmann followed up a few days later with an explanation on his personal blog. There he named udev as the culprit for the non-portability of some Xfce features:
But then Pohlmann points to the broader context:
Some Linux users, who may be used to six-month release cycles, might not see a problem here, as they now have all those new features. But the BSD operating systems generally have a much slower development life cycle and haven't caught up yet with the whole redesign of the desktop stack. The comments on Pohlmann's blog post are instructive in this regard (although somewhat degenerating into a flame war at the end). For example, one commenter points out that HAL did acquire BSD (and Solaris) support, but only years after it had been mainstream in the Linux world, and the BSD developers only contributed the necessary patches to make it work when Gnome and KDE started making HAL mandatory.
The problem seems to be that udev is not as easy to port to non-Linux systems as HAL was. FreeBSD has the devd daemon to handle volume mounting, but devd's author Warner Losh commented that udev is not well documented, which hampers efforts to port it. However, this didn't stop Alex Hornung from porting udev to DragonFly BSD, although it's not yet a full drop-in replacement. The FreeBSD developers could take a look at his work, as DragonFlyBSD is a FreeBSD derivative.
OpenBSD developer Marc Espie also points to license issues: udev and other software close to the Linux kernel is using GPLv2, which the BSDs don't like to use. For example, OpenBSD developers don't add a component to the base system if it's less free than the BSD license, and the GPL is such a license in their eyes. However, the current problems are also clearly a consequence of different development styles. Components like udisks are part of the Freedesktop specifications (which are supposed to keep X Window System desktops interoperable), but the BSD developers didn't seem to participate in that effort. Maybe the PC-BSD developers can play a role in this, as they want to deliver a modern desktop operating system based on FreeBSD.
All in all, there are two possible solutions to a situation like the one the Xfce 4.8 release is facing. One solution is that the Xfce developers create an abstraction layer supported by as many operating systems as possible. The problem is that currently there is no such abstraction layer for detecting devices, which makes it perfectly understandable that the Xfce developers chose udev. It is used by their major development platform, Linux, and one can't expect them to support frameworks on operating systems they don't use. So the other solution is that some BSD developers port udev to their operating system, which is non-trivial but (as the incomplete DragonFly BSD port shows) doable, or that they propose an abstraction layer that could be supported on non-Linux platforms. As many desktop applications have already been rewritten in the last few years from using HAL to using udev, the latter won't be a popular choice and isn't likely to happen.
X.Org and KMS
Another important desktop component that is becoming more and more Linux-centric in recent years is X.Org. Recent open source video drivers (such as the Nouveau driver) require kernel mode setting (KMS), which is a problem for the BSDs and OpenSolaris, as these operating systems lack kernel support for KMS and Graphics Execution Manager (GEM). So a FreeBSD user who wants to get decent performance out of an Nvidia graphics card, currently has to use the proprietary driver. Fortunately, the FreeBSD Foundation recognized the gravity of this situation and announced last year that it was willing to sponsor a developer to work on KMS and GEM support in the FreeBSD kernel. Last month, the foundation announced that it had awarded a grant, co-sponsored by iXsystems (the developers of PC-BSD) to Russian developer Konstantin Belousov to implement support for GEM, KMS, and Direct Rendering Infrastructure (DRI) for Intel hardware. Matt Olander, Chief Technology Officer at iXsystems, says in the announcement:
More specifically, Belousov will implement GEM, port KMS, and write new DRI drivers for Intel graphics cards, including the latest Sandy Bridge generation of integrated graphic units. After this work, users should be able to run the latest X.Org open source drivers for Intel on their FreeBSD desktop. While the project is limited to Intel graphics, porting other drivers like Nouveau to FreeBSD will become a lot easier once Belusov's work is completed. And when KMS support is in place, FreeBSD users could run the X Server without root privileges, run the Wayland display server, and get access to a lot of other features that are until now only available on Linux.
This case also shows that cutting edge development often happens with Linux primarily in mind. During the last few years, X.Org's drivers were in a constant state of flux, with new technologies like KMS, GEM, translation-table maps (TTM), DRI, Gallium3D and so on being introduced one after another. As these are low-level technologies tightly coupled to the Linux kernel, porting them to FreeBSD is no small task, but fortunately the FreeBSD Foundation and iXsystems have seen that it is very important to follow the lead of Linux here.
systemd
An entirely different case is systemd: Lennart Poettering has no problem with the fact that systemd is tightly glued to Linux features. In a recent interview for FOSDEM, Poettering sums up the Linux-specific functionality systemd relies on: cgroups, udev, the fanotify(), timerfd() and signalfd() system calls, filesystem namespaces, capability sets, /proc/self/mountinfo, and so on. And then comes this quote, explaining why he designed systemd with Linux in mind:
Poettering took this decision because of his experience in writing some other low-level components in the desktop stack:
He even goes further with this provocative invitation to other developers to do the same:
Poettering touches some interesting points here. We have a family of standards that are known as POSIX (Portable Operating System Interface for uniX), defining the API of a Unix operating system. However, the POSIX specifications are not carved in stone and there are few operating systems that are fully compliant (Mac OS X is one of them since the Leopard release). POSIX is really an encapsulation of some choices that various Unix systems made along the way, rather than a body of text that got standardized and then implemented. According to Poettering, Linux should use its position as "market leader" (in the market of free Unix-like operating systems) and try out some new things. If developers don't force themselves into the constraints of the POSIX API, they could develop some really innovative software, like systemd shows. When these new developments happen to turn out really interesting, other operating systems could eventually adopt them as well.
The tension between portability and innovation
These three cases clearly show that there's a constant tension between portability and innovation, which are two important qualities of open source software. In a lot of domains, Linux is taking the lead with respect to innovation, and the BSDs are forced to follow this lead if they don't want to be left behind. While the BSDs will probably not be interested in adopting systemd, implementing KMS is a must-have because one cannot imagine a modern X.Org desktop any more without it. But the biggest portability problems will be in the layers right above the kernel that don't have suitable abstraction layers, such as the Xfce case shows. Will FreeBSD implement udev or will the problem be solved another way? These kinds of questions are important and choosing when to use the POSIX or the Linux API is a delicate balancing act: choosing a Linux-centric approach for a low-level component like systemd is understandable because of the performance and maintenance gains, but most applications won't necessarily benefit from that approach.
But maybe the biggest problem these cases hint at is that Linux
development is being done at such a fast pace that other operating systems
just can't keep up. Linux distributions and Linux-centric developers are used to the "release early, release often
" mantra, including swapping out key components and breaking APIs each release. The BSD world doesn't work that way, and this makes working together on a modern cross-platform open source desktop increasingly difficult. The innovation of Linux inevitably comes at a price: Linux is the de facto Unix platform now, and hence more and more programs will not be portable to other operating systems.
Brief items
Quotes of the week
+ log_warning("/usr appears to be on a different file system than /. "
+ "This is not supported anymore. "
+ "Some things will probably break (sometimes even silently) "
+ "in mysterious ways.");
Burt: Canonical's New Plan for Banshee
Gabriel Burt has posted an update on his blog regarding the default music store for Banshee on Ubuntu. The new plan is as follows:Based on the wording in the blog post, this would seem to be a unilateral decision by Canonical/Ubuntu and one that, perhaps, the Banshee developers are not completely happy with. (Thanks to Jeff Schroeder.)
- Banshee's Amazon store will remain enabled, with Canonical taking a 75% cut of all affiliate revenue; 25% on Ubuntu will now go to the GNOME Foundation.
- The Ubuntu One store for Banshee will remain enabled by default, but now Canonical will donate 25% of its revenue to GNOME. They will now do the same for Rhythmbox.
Developments in GNU Radio
The FSF has put out a release describing recent changes to GNU Radio. "VOLK provides a way to access the vector (i.e., SIMD) instructions of general purpose processors. While there are other ways of doing this, a goal of GNU Radio is cross-platform support and an ease of programming and implementing new signal processing features. Until VOLK, adding SIMD code to GNU Radio had been a difficult, assembly-driven process. Instead, VOLK introduces the concept of a vector kernel to perform common mathematical functions in a cross-platform library. Over the next year, we will be improving many of the low-level signal processing blocks by using VOLK kernels instead of generic C++ code."
Mercurial 1.8 released
Version 1.8 of the Mercurial distributed version control system is available. New features include bookmarks, certificate validation for HTTPS proxies, support for git subrepositories, some performance improvements, and more. See the "what's new" page for details.SciPy 0.9.0 released
SciPy is a Python-based package of tools for science and engineering; the 0.9.0 release is now available. New features include Python 3 support, Delaunay tesselations, N-dimensional interpolation, some new large-scale nonlinear equation solvers, and more.Upstart 1.0 released
Scott James Remnant has announced the 1.0 release of the "upstart" init daemon. "The trouble with a '1.0' release is that the temptation is for that version to be the one with all the features you want when your users want it to be stable. This is a 1.0 release of the latter kind, based on the 0.6.x code that was shipped in both the most recent Ubuntu LTS and RedHat Enterprise Linux releases. If you're running Upstart anywhere right now, it's highly recommended that you update to this version, there shouldn't be any surprises!"
xorg-server 1.10.0
Version 1.10.0 of the X.org server is out. There's a long list of patches, but, seemingly, no release notes calling out the more important changes. See the announcement (click below) for the short-form changelog.
Newsletters and articles
Development newsletters from the last week
- Caml Weekly News (March 1)
- PostgreSQL Weekly News (February 27)
- Tcl-URL! (March 1)
An Early Look at GNOME 3.0 (Linux.com)
Nathan Willis takes GNOME 3 for a test drive. "Plenty of low-level stuff is in there, too, even though you might not see it. GNOME is migrating away from the old gconf configuration system to GSettings, which uses dconf and will enable new features like PolicyKit. The "preferences" and "administration" menus from GNOME 2.x have been combined into a single control-panel application. There is also a new window manager named Mutter, which combines the existing WM features of Metacity with compositing like that done by Compiz."
Page editor: Jonathan Corbet
Next page:
Announcements>>